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[57] ABSTRACT 

A system and method for managing user accounts in a 
distributed network that provides authentication to a chent 
user account is provided. The system authenticates a user to 
a directory services database having a set of credential 
information, and a number of workstation objects and cre- 
ates a user account on the client according to configuration 
information associated with one of the workstation objects. 
Depending on the configuration information, the system will 
create the user account with the same set of credential 
information as a user account in the directory services 
database, or, create the user account with credentials having 
an alternate username and random password. The system is 
operable to store client workstation configuration 
information, and to associate other networking objects in the 
directory services database with the workstation object. 
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SYSTEM AND METHOD FOR MANAGING 
USER ACCOUNTS IN A COMMUNICATION 
NETWORK 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to client-server 
computer systcnis and, more particularly, to managing user 
accounts in a communication network. 

2. Related Art 

Computer systems commonly communicate through a 
communication network for the purpose of sharing infor- 
mation. These computer systems are typically general pur- 
pose computer systems that may function as either a 
"client", a "server", or both. A server computer system 
provides resources to client computers such as print, file, and 
fax services or the like. A client computer system is a system 
that \ises such resources. An example of a client system is the 
Windows NT workstation chent system available from the 
Microsoft Corporation and hereinafter referred to as a Win- 
dows NT client. Of the many available server systems, 
examples include the Novell NetWare and Windows NT 
server systems, available from Novell Incorporated and the 
Microsoft Corporation, respectively. These server systems 
will be referred to below as NetWare servers and Windows 
NT servers. 

The server and client communicate via messages con- 
forming to a communication protocol sent over the computer 
network. The server responds to request messages generated 
by clients, processes the request messages, and generates 
reply messages to the client. The client communicates with 
the server for the purposes of sharing information and 
accessing server resources. To access such resources, a the 
client-server system typically performs an authentication 
process to determine if the client is authorized to access the 
resources. 

An authentication process is a process of verifying the 
identity of a user attempting to access a system. The user can 
be a person, a computer system, or a process running on a 
computer system. The authentication process is generally 
initiated by a user through a user interface presented to the 
user on the client system, and is typically performed by a 
"login" process performed on the client system. The login 
process provides the user interface to the user and performs 
the authentication process. During the authentication 
process, the login process gathers authentication information 
referred to in the art as "credentials" from the user within the 
client user interface, and transfers the credentials to the 
server through the communications network using the com- 
munications protocol. The server then compares credential 
information provided by the client to credentials located on 
the server, which may be a file or database on the server 
having credentials for each user. The server then allows or 
denies access to a user account based on a result of the 
comparison. 

A user account is generally a service provided by a server 
wherein resources are provided to a user. Typically, there is 
a set of credentials associated with a user account. When 
proper credentials are provided to the server, that is, when 
the credentials provided by the user matches a set of 
credentials on the server, the user may be permitted to access 
a user account associated with the entered credentials. When 
the user obtains access, the user is referred to as being 
"logged on." When the user is logged on, the user may 
access one or more server resources based upon an access 
control list. An access control list (ACL) associated with a 
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resource contains information that is used to determine the 
level of access with which a particular user may access a 
resource. 

Credentials may include such types of information such as 

5 a "username" and "password". The username is a name used 
to identify the user and may have an associated password 
that is known by the user. The username and password are 
typically entered by a user within fields of the client user 
interface. The username and password are usually encrypted 

^0 and then forwarded to the server which may then permit or 
deny access according to the entered username and pass- 
word. Credentials may include additional information, 
depending on the type of server system being accessed. Such 
additional information may include login information for a 

15 database, a login script, or other information as permitted by 
the server. Other types of credential information used to 
identify a user are well-known in the art, including retinal 
scan and fingerprint information. 

Client systems may also require local credentials to access 
the local client system resources, such as a local "shell" and 
associated programs. Local credentials are credentials used 
for verification of the user to a local authentication process. 
The local authentication process authenticates a user and 
provides access to local resources. Thxis, a client may also 
have user accounts defined locally to the client, the accounts 
typically being created manually by a network administrator. 

A shell is a piece of software, usually a separate program, 
that provides communication between the user and the 
operating system. For example, the Windows Program Man- 
ager program in the Windows operating system is a shell 
program that interacts with the MS-DOS operating system 
available from the Microsoft Corporation. A client system 
that requires local credentials includes the Windows NT 

25 operating system available from the Microsoft Corporation. 
To access the Windows NT shell, referred to as the "desktop 
shell," a user may need to provide a username and password 
to a user interface of a client login program. The user is 
authenticated by the Windows NT operating system which 
then provides the user access to the desktop shell. On a 
Windows NT client, the login process is performed by a 
login program having several components including a Win- 
logon program and a Microsoft Graphical Identification and 
Authentication (MSGINA) program. The Winlogon 

^5 program, when executed, provides a process for authenti- 
cating and logging on the user. The MSGINA program is 
executed by the Winlogon program and is a replaceable 
component of the login program. The Winlogon program 
provides core functions such as authentication-policy inde- 
pendent functions and non-user interface functions. The 
MSGINA program provides authentication policy and iden- 
tification and authentication user interaction functions. 

To access a server system from such a client system, an 
additional authentication must be performed between the 

55 client and server systems. The credentials may be different 
between the client and server systems for a user, and thus the 
user may be required to provide a different set of credentials 
for each server system that is accessed. Administering 
accounts for both local and server systems may be unwield- 

50 ily for a network administrator responsible for maintaining 
accounts on the network. To alleviate the problem of per- 
forming both a client and server authentication on a Win- 
dows NT client and Windows NT server, a centralized 
system for account management referred to as Microsoft 

65 Domains was developed. 

The Microsoft Domains account management system 
allows the network administrator to define one or more 
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domains used by aD administrator to centrally manage 
Windows NT client accounts. A domain is a defined group 
of resources such as client workstations, printers, and the 
like, used to organize and maintain network resources. 
Administration of domains is typically performed by a 
network administrator with the assistance of an application 
program known as User Manager for Domains available 
from the Microsoft Corporation. There may be different 
types of domains, generally based upon the number of users 
and the level of security desired between domains. Admin- 
istration of domains may be complex for large networks 
having a large number of user accounts since the Microsoft 
Domains system provides a flat hierarchical view of user 
accounts and does not adequately handle a large number of 
users. Administration of domains may be unfamiliar to 
network administrators trained only in NetWare network 
administration since the domain hierarchy has a different 
structure than a NetWare network hierarchy which is a has 
tree hierarchy. 

A user may desire access to a NetWare server from a 
Windows NT client workstation. In many existing networks, 
the NetWare server operating system is a prevalent server 
type while Windows NT is currently a popular operating 
system for clients. It would be beneficial for Windows NT 
clients to freely share information and access NetWare 
server resources. However, for networks with both NetWare 
and Windows NT servers, the Microsoft Domains system 
does not provide authentication services for NetWare serv- 
ers. 

It also may be desired to incorporate Novell Directory 
Services (NDS) database functionality into the Windows NT 
operating system environment, since the NDS database 
provides a centralized source of network resource informa- 
tion and authentication process. The NetWare NDS 
database, through the use of the Microsoft Windows NT 
Explorer program, provides users and administrators with a 
view of NetWare network resources. This view simplifies 
network use as well as network administration and manage- 
ment. In addition, the NDS database, when used in conjunc- 
tion with an administrative program such as the NetWare 
Administrator, allows centralized network management and 
administration and automation of many administrative tasks. 

User account and credential information is stored within 
the NDS database for all users of a Novell network. The 
NDS database stores a number of objects, such as user 
objects, server objects, printer objects, and the like. The 
NDS database has an associated authentication process for 
authenticating users of the NDS database objects. When a 
user authenticates with the NDS authentication process, the 
user is provided access to multiple objects defined in the 
NDS database depending on an ACL associated with each 
object. Thus, a user may be authenticated once by the NDS 
authentication process to allow the user access to multiple 
systems on a Novell network, since the NDS authentication 
process authenticates the user to multiple objects transpar- 
ently. 

Problems in a client -server network using Windows NT as 
a client operating system with a Novell NetWare server 
include having to maintain credential information on both 
the cUent workstation and the server. Maintenance of mul- 
tiple sets of credential information requires significant 
administrator labor in networks having many client 
workstations, since an administrator must travel to client 
workstation locations to maintain client workstation 
accoimts. Also, manually synchronizing credential informa- 
tion frequently results in errors on behalf of the network 
administrator. 
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Furthermore, administrators must be trained to administer 
diff^erent authentication systems since users and groups are 
managed from separate administration programs. 
Specifically, in a NetWare operating system-based network 
(hereinafter referred to as a Novell network), it may not be 
preferred to implement the Microsoft Domains account 
management system since network administrators would 
require additional training for managing Microsoft Domains 
through the User Manager for Domains program. In 
addition, an administrator must be knowledgeable of the 
NetWare-based accoimt management program, the NetWare 
Administrator program available firom NoveU Incorporated. 

What is needed, therefore, is a system for maintaining 
credential information between client and server accounts 
and for managing user accounts from a central location that 
can provide authentication to different types of server 
systems, such as Novell NetWare and Windows NT 

SUMMARY OF THE INVENTION 

The invention includes a system for authenticating a user 
to multiple systems. In addition, the system authenticates to 
a client workstation in a manner transparent to the user, and 
generates a user account on the client workstation if the user 
account does not exist. Further, the system provides a 
workstation object to a directory services database, permit- 
ting a network administrator to efficiently manage client 
workstation accounts through an existing management pro- 
gram. Also, since the existing management program and 
directory services database are modified to manage client 
workstations, a network administrator does not have to visit 
each client to setup user accounts. Since user account 
information is maintained in the directory services database, 
the system allows a user to roam to different workstations 
and access the same user accounts and workstation proper- 
ties. 

The invention further provides a system using a single set 
of credentials for accessing a plurality of servers that are 
centrally located and managed. Thus, simplification of 
administration is attained since an administrator does not 
have to maintain separate accounts on a shared workstation 
for all potential users. Administration is further simplified by 
eliminating need to manage users separately in a directory 
services database and a domain database. Advantageously, 
the client is allowed to access network resources defined in 
the directory services database. 

In another aspect of the invention, a method is provided 
for managing user accounts in a network having a client and 
server, the method comprising the steps of logging in a user 
to a first server having a database, the database having a first 
set of credential information, accessing a workstation having 
associated configuration information, based on the configu- 
ration information, generating a user account on the client, 
and logging the user in to the client account using the first 
set of credential information. In another aspect, the gener- 
ating step includes the steps of starting a timer when the 
client account is generated and deleting the client account 
when the timer exceeds a predetermined time. Significantly, 
accumulation of excess user accounts on the client is pre- 
vented. 

In another aspect of the invention, a system is provided 
for authenticating a user to a client workstation having a 
security accessor, the system comprising a login process 
being operable to create a user account on the client work- 
station and a directory services authenticator providing 
credentials to the login process, wherein the login process 
authenticates a user to the security accessor using the 
credentials. 
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In another aspect of the invention, a client-server system 
is provided for managing user accounts in a communication 
network, the system comprising a directory services data- 
base having a plurality of network objects, and a client 
administrator associated with the directory services 
database, configured to create a plurality of client objects in 
the directory services database. In another aspect, the client- 
server system further includes means for associating one of 
the plurality of client objects to at least one of the plurality 
of network objects. Advantageously, objects in the directory 
services database may be associated with workstations and 
their configurations. 

Further features and advantages of the present invention 
as well as the structure and operation of various embodi- 
ments of the present invention are described in detail below 
with reference to the accompanying drawings. In the 
drawings, like reference numerals indicate identical or func- 
tionally similar elements. Additionally, the left -most one or 
two digits of a reference numeral identifies the drawing in 
which the reference numeral first appears. 

BRIEF DESCRIPTION OF THE DRAWINGS 

This invention is pointed out with particularity in the 
appended claims. The above and further advantages of this 
invention may be better understood by referring to the 
following description when taken in conjunction with the 
accompanying drawings, in which: 

FIG. 1 is a block diagram of an exemplary computer 
system suitable for incorporating an embodiment of the 
present invention; 

FIGS. 2A-C are block diagrams depicting an exemplary 
client-server system incorporating an embodiment of the 
present invention; 

FIG. 3A is a block diagram of an exemplary directory 
services database; 

FIG. 3B is a block diagram of user and client workstation 
objects according to an embodiment of the present inven- 
tion; 

FIG. 3C is a block diagram showing credential informa- 
tion; 

FIG. 4 is a flowchart exemplifying the operation of a login 
process according to an embodiment of the present inven- 
tion; 

FIG. 5 is a flowchart exemplifying the operation of a 
process for authenticating a user with a directory service; 

FIG. 6 is a flowchart exemplifying the operation of a 
dynamic login process; 

FIG. 7 is a flowchart exemplifying the operation of a 
server credentials process; 

FIG. 8 is a flowchart exemplifying the operation of a local 
credentials process; 

FIG. 9 is a flowchart exemplifying the operation of a 
non-dynamic login process; 

FIG. 10 is a flowchart exemplifying the operation of a 
user object inspection process; and 

FIG. 11 is a flowchart exemplifying the operation of a 
logout process. 

DETAILED DESCRIPTION 

The present invention will be more completely under- 
stood through the following detailed description which 
should be read in conjunction with the attached drawings in 
which similar reference numbers indicate similar structures. 
All references cited herein are hereby expressly incorporated 
by reference. 
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An example computer system which may be used to 
practice the present invention is depicted in FIG. 1. The 
computer system 101 includes a processor 105 connected to 
one or more storage devices 109, such as a disk drive. The 

5 computer system also includes one or more output devices 
108, such as a monitor or graphic display 112, or printing 
device (not shown). The computer system 101 typically 
includes a memory 106 for storing programs and data during 
operation of the computer system 101. In addition, the 
computer system may contain one or more communication 
devices 110 that connect the computer system to a commu- 
nication network 104. 

Computer system 101 may be a general purpose computer 
system that is programmable using a hi^ level computer 
programming language. The computer system may also be 
implemented using specially programmed, special purpose 
hardware. In the computer system 101, the processor 105 is 
typically a commercially available processor, such as the 
PENTIUM microprocessor firom the Intel Corporation, Pow- 
erPC microprocessor, SPARC processor available from Sun 

20 Microsystems, or 68000 series microprocessor available 
from Motorola. Many other processors are available. Such a 
processor usually executes an operating system which may 
be, for example, the DOS, WINDOWS 95, WINDOWS NT 
available from the Microsoft Corporation, MAC OS SYS- 

25 TEM 7 available from Apple Computer, SOLARIS available 
from Sun microsystems, NetWare available from Novell 
Incorporated, or UNIX available firom various sources. 

The communication network 104 may be an ETHERNET 
network or other type of local or wide area network (LAN 

30 or WAN), a point-to-point network provided by telephone 
services, or other type of communication network. As dis- 
cussed above, information consumers and providers, 
referred to as client 103 and server 102 systems, 
respectively, communicate through the network 104 to 

35 exchange information. Computer system 101 may be con- 
figured to perform as a client 102 or server 103 system or 
both on the network 104. A server 103 A and 103B may offer 
a number of resources to clients 102. The server typicaUy 
provides access to these resources in response to a request 

40 generated by a client 102A through the network 111. 

It should be understood that the invention is not limited to 
a particular computer system platform, processor, operating 
system, or network. Also, it should be apparent to those 
skilled in the art that the present invention is not limited to 

45 a specific programming language or computer system and 
that other appropriate programming languages and other 
appropriate computer systems could also be used. 

The present invention may be programed using an object- 
oriented programming language, such as Smalltalk, JAVA, 

50 or C++. In object-oriented programming, code and data that 
are related may be combined into objects. An object is an 
instance of an entity that embodies both specific data and the 
functions that manipulate it. In object-oriented 
programming, an object is an entity that has state, behavior 

55 and identity. Objects are created, or instantiated, during the 
execution of an object-oriented program wherein instances 
of objects are created. Objects may be related, as in a 
parent-child relationship, wherein features such as methods 
and/or data structures are inherited by a child object from a 

60 parent object. Objects are typically created in class 
hierarchies, and the methods and/or data structures of 
objects are inherited through the hierarchy. Other such 
relationships exist between objects. It should be understood 
that the present invention may be implemented in any 

65 object-oriented programming language suitable for authen- 
ticating clients with servers. In addition, the invention may 
be implemented using functional programming. 
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A more detailed block diagram of a client-server system created. When the value of the parameter supplied by a 

implementing one embodiment of the present invention is program is null, the NetUserAdd function creates a user on 

shown in no. 2 A, A client 102 A implementing the present the local workstation within the local access database 203. 

invention typically includes a networking protocol 201 used Another parameter includes a number of sub-parameters 

by an application program to communicate with servers 103. 5 such as usemame and password, wherein the username is the 

Examples of a networking protocol 201 includes a TCP/IP name of a new user to be created and the password is a 

networking protocol used to communicate over the Internet password to be assigned to the new user. The login process 

and other computer networks, and the IPX/SPX networking 207 may use either a directory services user name or an 

protocols available from the Novell Corporation. Other alternate user name specified by a workstation object 

networking protocols may be used. described below. Process 207 may use a directory services 

In addition, the client 102A includes a security accessor password entered by a user in a login screen generated by the 

202 which provides access on the local client 102A. Chent login process 207 or a randomly generated password if an 

102 A may be, for example, a Windows NT client and the alternate user name from the workstation object is used, 

security accessor 202 may be the well-known security Additional information may be specified which defines 

accounts manager (SAM). Specifically, SAM is a process additional attributes for the new account. Such information 

executed on a Windows NT client that monitors requests for includes an attribute that indicates that the password for the 

access to the local workstation. Local access requests may account should not expire, an attribute indicating that a 

be generated by an existing login process 205 by making default account should be created, and an attribute indicating 

function calls defined within a security Application Program that the password associated with the new account should 

Interface (API) 204 described in more detail below. The 20 change. The NetUserAdd function, when executed, will 

security accessor 202 accepts credential information pro- return information to the calling program indicating that the 

vided by functions in the security API 204 and compares the new account was successfully created, 

credential information to a local access database 203. If, the The NetUserGetlnfo function may be used by a program 

credential information matches a record in the local access to verify if a user account already exists in the local access 

database 203, the security accessor 202 allows the user to 25 database 203, A first parameter specifies firom which domain 

access client 102A. to obtain the user account information. A null value for the 

As shown in FIG. 2 A, there is a server 103B with which first parameter is used to obtain the user account information 

the client 102Acommonly communicates. Server 103B may from the local access database 203. The API function 

be, for example, a Windows NT server. Server 103B NetUserGetlnfo returns success information if the user 

includes a networking protocol 210 that is compatible with 30 account exists in the local access database 203. The 

networking protocol 201. On a Windows NT server, this NetUserGetlnfo function is also used to return information 

networking protocol may be TCP/IP. Other networking located in the local access database 203 concerning the user 

protocol types are available. Also on server 103B, is a account. The NetUserGetlnfo function returns information 

domain authentication process 211 that provides authenti- associated with the user account such as the full name of the 

cation to a domain defined on the server. The domain and its 35 user, the description of the account, and any account flags 

users are defined within a domain database 212. The domain and restrictions placed on the account, 

database may be, for example, a database having a flat The NetUserSet Info function may be used by an appli- 

structure such as the Microsoft Domains database. The cation program to set a password associated with a user 

domain authentication process 211 compares credentials account. If a first parameter is set to a value of null, the 

contained in a request for access generated by the client 40 NetUserSetlnfo function may use an account within the 

102 A to entries within the domain database 212. If the local access database 203. The function also accepts a 

credentials provided by the client 102A match a credential usemame designating the account for which the password 

record in database 212, the domain authentication process will be changed or set. Generally, the login process 207 will 

211 allows access to the server process 213 and associated use a directory services useraame for the local account. The 

server resources 214. The level of access provided to the 45 NetUserSetlnfo function will return information to the caU- 

client 102A to the server resource 214 depends upon access ing program indicating that the password associated with the 

information stored within the domain database 212. account was successfully set. 

As discussed above, the existing login process 205 pro- The NetUserDel function may be used by an application 
vides access to a server resource 214 located on server 103B, program to delete a user account. This function may be used 
Access is provided by the security accessor 202 through 50 when deleting a volatile user account (described below) 
calls made to the security API 204. Generally, an API is a during logout or shutdown of the client 102A as described 
collection of programs which may be used by a program to below with respect to FIG. 11. If a first parameter is set to 
perform functions on a system. On a Windows NT client, a null value, the user account which is deleted will reside in 
this API 204 is the Win32 API used to manage access to the local access database 203. A usemame parameter is 
domains in the local access database 203. The Win32 API is 55 accepted by the NetUserDel function, the useraame being 
available for use by program developers to develop pro- the local user account to delete. The login process 207 may 
grams requiring access to Microsoft domains and Windows be either the directory services user account or an alternate 
NT workstation account information. A program which user account defined by the workstation object. The 
accesses functions provided by the Win32 API will be NetUserDel function returns information to the calling pro- 
referred to hereinafter as a "calling program," that is, a 60 gram indicating that the user account was successfiilly 
program that executes another program. deleted. 

The Win32 API includes a number of functions for The NetLocalGroupAddMember function may be used by 

performing operations with credential information. The an application program to add newly-created user to a user 

Win32 API includes the NetUserAdd function used to create group according to group information associated with the 

a new user on a local Windows NT workstation, llie 65 workstation object. The first parameter specifies which 

NetUserAdd function accepts a number of parameters. A domain to associate members to groups. When the first 

first parameter specifies in which domain a user account is parameter has a null value, the NeiLxtcalGroupAddMembers 
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function associates a user to groups defined in the local executed wherein the process 207 has adnainistrative privi- 

access database 203. The NetLocalGroupAddMembersfu DC- leges. By having administrator-level privileges, the login 

tion accepts a group name which is a name of the local process 207 may dynamically create and delete Windows 

group. The identifier/authenticator 207 obtains the group NT client user accounts. Administrator level privileges are 

name from the workstation object described below. The $ typically provided when a user is logged into an adminis- 

NetLocalGroupAddMembers function also accepts a local trator account. The administrator account generally has 

domain name which is arbitrarily set to the local client name access to all resources, that is, the administrator account is 

followed by the directory services user name by the login listed as having access in ACLs of the resources. An 

process 207. The function returns information to the calling embodiment of the invention provides a second component 

program indicating that the user was successfully added to which provides an administrator the ability to administer 

the group. client accounts from the directory services database 223. 

The NetLocalGroupDelMembers function may be used This administrative ability is provided by a client worksta- 

by an application program to remove a user from a group lion administrator 232 described below in reference to FIG. 

when a workstation object no longer associates the user to 2C. Thus, an administrator may administer client accounts 

the group. The NetLocalGroupDelMembers function without having to implement Windows NT servers and a 

accepts a first parameter specifying which domain to remove Microsoft Domain database. 

users from groups. When the first parameter has a value of In an embodiment of the present invention, a login 

null, the NetLocalGroupDelMembers function removes process 207 is provided and used in lieu of the existing login 

users from groups defined in the local access database 203. process 205. In the Windows NT environment, use of one 

The function also accepts another parameter whose value is 20 program in lieu of another is facilitated by modifying a 

the name of the local group. The login process 207 obtains registry on the Windows NT client. A registry is a configu- 

this group name firom the workstation object. As in the ration database known in the art of Windows programming 

NetLocalGroupAddMembers function, the NetLocalGroup- and used to store configuration data associated with Win- 

DelMembers function accepts another parameter whose dows programs and the Windows NT operating system. The 

value is the domain name which is arbitrarily set to the local 25 login process 207 is executed by modifying a reference in 

computer name followed by the directory services user the registry to execute a program associated with login 

name. The function returns information to the calling pro- process 207 in lieu of the existing program associated with 

gram indicating that the user was successfully removed from the 205 login process. Modifying the Windows NT registry 

the group. is well-known in the art of Windows 95 and NT system 

The NetUserGetLocalGroups function may be used by an 30 programming, 

application program to determine what local groups a local Also as shown in FIG. 2A, there may be a client 102B that 

user belongs to. The NetUserGetLocalGroups function provides an administrator access to provide administration 

accepts a first parameter which specifies the domain wherein to the directory services database 223. The client 102B 

the user account is located. When the first parameter includes a networking protocol 230 that is compatible with 

assumes a null value, the NetUserGetLocalGroups function 35 networking protocol 220 on server 103 A. The client 102B 

obtains group information from the local access database includes a directory services administrator 231 which may 

203. The NetUserGetLocalGroups function accepts a user be an application program used to perform administrative 

name parameter which is the name of the local user account functions on the directory services database 223. In an 

for which the calling program wishes to obtain the associ- embodiment of the invention, a client workstation adminis- 

ated group list, llie function returns the groups associated 40 trator 232 is provided to the directory services administrator 

with the user account, and, if successful, returns the group 231 for administering client 102 A workstations. The direc- 

information to the calling program. tory services administrator 231 may be, for example, the 

FIG. 2A shows a server 103A having a number of server NetWare Administrator application program available from 

resources 224. A user desires access to such resources 224. the Novell Corporation, used by a network administrator for 

Server 103A also includes a networking protocol 220, which 45 administering an NDS database. As discussed below, the 

is compatible with networking protocol 201. Also, server cUent workstation administrator 232 may be used to provide 

103A includes a directory services authenticator 221 used additional administrative functions related to client 102A. 

for authenticating users to the server 103A. The directory Such administrative functions may include setting client 

services authenticator 221 accepts credential inforaiation 102A operating system settings, editing accounts on client 

transmitted by the client 102A through the network 104 and 50 102A or other similar administrative tasks, 

compares this credential information with a directory ser- The client workstation administrator 232 may be, for 

vices database 223. If, in the directory services database 223, example, a dynamic link Mbraiy (DLL) provided with the 

there exists a credential record matching the credential NetWare administrator application program. A dynamic fink 

information provided by the client 102 A, the user is pro- library allows an apphcation program to include only the 

vided access to the server process 222 and any server 55 information the program requires at load time or run time to 

resource 224 associated with the user account. The creden- locate the code for an exported DLL function. Thus, by 

tials provided by a user to server 103A are referred to as exporting functions to a DLL, code associated with a func- 

directory services credentials. The server 103A may be, for tion may be loaded into memory of the system only when the 

example, a NetWare server having a NDS database 223. The function is required. The use of DLL functions are well 

server process 222 would be, in this case, a NetWare server to known in the art of Windows programming, 

process and its associated resource would be a NetWare FIG. 2B shows a more detailed view of an embodiment of 

resource. a client server system. As shown, a user provides input/ 

Significantly, an embodiment of the present invention output 217 through a login interface 208 of the login process 

provides several components. The first component is the 207. The input/output includes information such as creden- 

login process 207 that collects credential information from 65 tials supplied to the login interface 208 and output such as 

the user and performs authentication to servers 103A and informational messages indicating successful or unsuccess- 

103B. On a Windows NT client, the login process 207 is fill login attempts. The login interface 208 may supply 
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additional user information, such as displaying text mes- to contact server 103 A. The objects directory services 

sages or bitmaps provided by an administrator. administrator 231 generates a request through network 104, 

The login process 207 also includes an authentication and the request is received by the networking protocol 220 

process 209 used to authenticate a user to the local client located on the server 103A. The request is forwarded to the 

102A as well as servers 103A and 103B. A subset of 5 directory services authentication process 221 which, when 

functionality within the authentication process 209 is pro- provided the proper administrative credentials, will allow an 

vided by the existing login process 205 for accessing only administrator to modify the directory services database 223. 

the client workstation 102Aand server 103B. On a Windows An administrator may desire to add or delete user accounts 

NT client 102 A, the existing login process 205 includes an located on client 102Aor configure a number of workstation 

authentication process referred to as the Microsoft Graphical jg objects described below. 

Identification and authentication (MSGINA) module. The Referring now to FIG. 3 A, a more detailed view of an 

MSGINA module is provided as a DLL and is well docu- exemplary NDS database is shown. The NDS database 223 

mented in the Win 32 Software Development Kit (SDK), structure, which is well-known in the art of NetWare 

available from the Microsoft Corporation, incorporated programming, contains two types of objects, container 

herein by reference. The authentication process 209 of an objects and leaf objects. Container objects, or parent objects, 

embodiment of the present invention may be, for example, contain other container objects or leaf objects. Leaf objects 

referred to as the NetWare Graphical Identification and are generally representations of networking entities such as 

Authentication (NWGINA) module having the additional servers, printers, users, volumes or the like. The NDS 

ability to authenticate a user with a NetWare server 103A database 223 hierarchy includes a root object 301 which is 

and its associated NDS database 223. 20 ^ ^yP^ container object and is the top most object in what 

The authentication process 209 stores credentials pro- is commonly referred to as an NDS tree. The root object 301 

vided by the user in a local credentials storage location 216. provides an access point to different country 302 and orga- 

The local credentials information 216 will be discussed in nizational 303 objects. The country objects 302A and 302B 

more detail below with respect to FIG. 3C. The login process are optional container objects that may include organiza- 

207 may also include a time stamp mechanism 215 used for 25 ^ional objects 303 or alias objects (not shown) that link to 

deleting credential information on the local workstation or other objects in the NDS tree. As shown in FIG, 3A, an 

deleting accounts created in the local access database 203. organization object 303 A may contain one or more container 

An administrator may set a persistence parameter which objects such as an organizational unit object 304A and 304B 

represents the length of time that a user account may reside used to further subdivide groups of network entities, 

in the local access database 203. This persistence parameter 30 An organization object 303B may include leaf objects 305 

value may be a predetermined time determined by an such as a group object 305B used to associate a number of 

administrator. When the persistence parameter value is leaf objects in a group, a server object 305C used to 

exceeded, that is, the user account has existed on client 102A represent a NetWare server, a user object 305D used to 

longer than the value of the persistence parameter, the user represent a user, a printer object 305E which represents a 

account 203 is deleted from the local access database 203. 35 printer available on the Novell network, and a volume object 

The persistence parameter may be stored as a login param- 305F used to represent a file volume located on a NetWare 

eter of a client workstation object described in further detail server. The directory services database 223 may be extended 

below with reference to FIG. 3B. to support other types of container and leaf objects, such as 

The authentication process 209 and time stamp mecha- the client workstation object 305G provided by an embodi- 
nism 215 call security API functions 204 described above 40 ment of the present invention. The client workstation object 
for accessing the local access database 203 through the 305G represents a client workstation 102A such as a Win- 
security accessor 202, The authentication process 209 dows NT workstation and its configuration, 
directly contacts server 103 A using networking protocol 201 FIG. 3B shows a user object 305D and client workstation 
for authenticating a user to the directory services database object 305G in further detail. These objects may include a 
223. Access is provided by the directory services authenti- 45 number of parameters for storing information associated 
cation process 221, which accepts credential information with users and client workstations. For example, the user 
enclosed within an access request provided by client 102A. object 305D may include a usernarae parameter 311 that 
Credential information may be, as known in the art, may be stores the username associated with a user account. User 
transferred by a login program having authentication keys. object 305D may be "associated" with another object, that 
Such a system is provided by the RSA authentication 50 is, one object is linked to another object. Associations may 
algorithm, described in detail in Network Security, Private be performed between NDS objects, such as associating a 
Communication in a Public World, by C. Kaufinan, R. number of user objects 305D to a group object 305B. The 
Perlman, and M. Speciner, incorporated herein by reference. group object 305B has a member list, which is a list of 
Security key authentication is well-known in the art of pointers to objects to which the group object is associated, 
computer programing and the present invention may use any 55 Another type of association is an association to a client 
security mechanism known currently or in the future. workstation object 305G. The association is performed by a 
Generally, credential information is encrypted before trans- client workstation configuration pointer 312 which refer- 
mission on network 104. ences a client workstation object 305G. Similar to the user 

A client-server system according to one embodiment of object 305D, the client workstation object 305G provided by 

the present invention is shown in FIG. 2C. In this 60 an embodiment of the present invention, may include a 

embodiment, the ability to administer the directory services number of parameters. 

database 223 is provided. As shown, an administrator pro- The client workstation object 305G may include user 
vides input/output 234 to the directory services administra- profile parameters 313 which store information relative to 
tor program 231. The directory services administrator pro- settings for the desktop shell program executed on client 
gram 231 is augmented with a client workstation 65 102A. Such settings may include parameters such as win- 
administrator 232 described above. The directory services dow colors, positions of icons, or other settings for the user 
administrator 231 program utilizes networking protocol 230 environment provided by the desktop shell program. On a 
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Windows NT client, the user profile 313 is referred to as Login information 315 may also include a server creden- 
Windows NT user profiles. The user profile 313 is typically tials flag 318 which identifies whether the same credential 
a pointer to a configuration file located on a file system of set used for authentication to the directory services database 
server 103A. The user profile parameters 313 include set- 223 or a predetermined credential set specified in the work- 
tings for the Windows NT desktop shell. Since the Windows 5 station object 305G. When using directory services database 
NT user profile is accessible through the NDS database, 223 credentials to create the client user account, the authen- 
users may access their desktop profiles from various clients tication process 209 queries the users directory services user 
throughout the network. account for the user name, and associated information. In a 
The client workstation object 305G may include a group preferred embodiment, the password generated for the 
memberships parameter 314 which stores any group mem- account in the local access database 203 is the same as the 
berships associated with a cliem workstation. When the directory services user account password. If server creden- 
authentication process 209 creates an accoum in the local ^ials are not used, then other credentials may be used, such 
access database 203, process 207 may provide group mem- ^s the credentials specified in the user name 319 parameter 
bership to a user account. The groups to which the user is ^^e chent wor^tation object 305G and a randomly- 

.\j . u • . generated password. The user name 319 stores a default user 

associated may be added through a user mterface program ^^^^ ^^^^^ ^^^^ randomly.generated 

used to admmister the directory services database 223, such g^^rd associated with user name 319 may be generated 

as the duectory services admmistrator application program . authentication process 209 and is generally not 

231. When the login process 207 creates the client 102A accessible by the user. 

account in the local access database 203, the user may be ^ogin information 315 may include any references to 

added to a users group and an admmistrator group. Other 20 scripts or programs external to the login program to be 

groups may be added through the directory services admin- executed upon login to the client 102A. The locations and 

istrator program 231. execution settings for these scripts or programs may also be 

The client workstation object 305G may include login included within login information 315. Also, any messages 

information 315 having a number of sub-parameters. Such or bitmaps to be displayed by an administrator in the login 

sub-parameters may include a volatile user flag 316 used to 25 interface may be included within login information 315. As 

specify whether a new account created on the client 102A discussed above, login information 315 may also include a 

should be deleted from the local access database 203 when persistence parameter which determines when a user 

a user logs out of the client 102A. If the account in account will be deleted from client 102A. 

nonvolatile, a user account is created in the local access A network administrator may provide access for different 

database 203. When the user logs into the client 102A and 30 directory services users and, therefore, can create a number 

the account remains in the local access database 203 after the of different cUent workstation objects 305G. Directory ser- 

user logs out of the client 102A. The new account is then vices users may be associated with a client workstation 

available for later use, perhaps if the user logs into the cHent object 305G using associations available in the directory 

102A at a later time. services administrator program 231 . Directory services users 

A volatile user account does not remain within the local 35 ^^^V associated with a chent workstation object 305G 

access database 203. When the user logs into the chent 102 individually or through group and container a^ociaUons. 

with a volatile user account, and the user logs out of that Associations between NDS objects may be added through a 

account, the login process 207 deletes that user account. user interface presented to the admmistrator during the 

AdvanUgeously, deletion of accounts prevents a large num- execution of the duectory services admmistrator program 

ber of user accounts from accumulating on the client 102A. 40 231. Associations between NDS objects are weU-known m 

Also, deletion of accounts also prevents users from gaining the art of NetWare user account administraUon. 

access to the client 102A without first authenticating to the Once a user object 305D has been associated with a client 

server 103A, since the credentials needed to access the workstation object 305G, the login process 207 may retrieve 

account are deleted from the local access database 203. The user information from the workstation object 305G to create 

volatile user flag 216 parameter may be set through the 45 a user account on the client 102A. 

directory services administrator 231 user interface as Significantly, the client workstation object 305G allows 

described above, user profiles to be accessed from multiple clients in the 

Login information 315 may also include a dynamic login network 104. When a user logs in from a client other than the 

flag 317 used to indicate whether user information should be user's "normal" client 102A, that is, the client that the user 

retrieved from the client workstation object 305G to create 50 normaUy logs into, the authentication process 209 loads a 

a user account on the client 102A. When the login process user profile 313 associated with the user and configures the 

207 inspects a workstation object 305G, the login process desktop according to information contained in the user 

207 may need to identify if a user account should be created profile 313. A user having access to a centralized user profile 

in the local access database 203. If dynamic login is not 313 may load the same desktop configuration regardless of 

enabled, the login process 207 does not create a user in the 55 the client on which the user is located. Further, user profile 

local access database 203, but instead attempts to find an 313 information may override a client's defauU parameters, 

existing user account in the local access database 203, the An administrator may modify the user profile 313 associated 

account having credentials as supplied by a user to the login with a client workstation object 305G and thus, when a user 

interface 208. If dynamic login is enabled, then the authen- logs into a workstation associated with the client worksta- 

tication process 209 obtains the client user name from the 60 tion object 305G, will modify the client's desktop configu- 

workstalion object 305G and queries the local access data- ration. As discussed, settings for a Windows NT client are 

base 203 to verify that the user name already exists. If the contained in the registry. Information contained in the user 

user name exists, the authentication process 209 authenti- profile 313 may override settings in the registry. Thus, the 

cates the user to the client 102A and access is granted to the administrator is provided a system for automatically updat- 

user. If the user name does not exist, then the authentication 65 ing chent system settings. 

process 209 creates a user account within the local access FIG. 3C shows the credentials that are required for the 

database 203. various systems. The login dialogue 330 typically presented 
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to the user at the client 102A by the existing login process the server 103A receives the credential information and 
207 includes a usemame 335 and password 356. To access transfers the credentials to the directory services authenti- 
server 103A, a typical server 103A login dialogue 331 cator 221. The directory services authenticator 221 locates 
prompts the user for a directory services usemame 337 and the user name within the credential information and inspects 
password 338, a directory services tree 339, a preferred 5 a user object 305D associated with that user name 311. If, 
server 340, and a directory context 341, the context 341 the user object 305D is associated with a client workstation 
being the location in the directory services tree hierarchy to object 305G, the directory services authenticator will read 
where the user will authenticate. The directory services the client workstation object 305G configuration associated 
usemame 347 may correspond to a usemame 311 of a user with the user object 305D as indicated by the client work- 
object 305D in the directory services database 223. Atypical 10 station configuration pointer 312. If, at block 508, it is 
server 103B login dialogue 332 would present the user with determined that dynamic login is enabled, that is, the 
an interface requesting a username 342, a password 343, and dynamic login flag 317 is set, then the login process 207 will 
a local client/domain name 344. Local client/domain 341 perform the dynamic login process at block 510. If dynamic 
may store the name of a domain or the name of a client login is not enabled, the login process 207 wiU perform a 
workstation to which the authentication process 209 authen- 15 non-dynamic login process 512. At block 514, process 406 
ticates. As discussed above, the local credentials 216 changes group memberships according to the group mem- 
includes credential information for systems 102A, 103A and berships 314 specified in the client workstation object 305G. 
103B. The local credentials 216 includes storage locations At block 516, the local credentials 216 are updated accord- 
for a directory services usemame 345 and password 346, a ing to any updated credential information created during 
tree 347, a preferred server 348, a directory context 349, an 20 process 400. At block 518 the authentication process 
alternate usemame 350 and password 351, and a local 406 ends. 

account or domain 352. The storage locations in the local FIG. 6 shows a dynamic login process according to an 

credentials correspond to parameters required by dialogs embodiment of the invention. A dynamic login process is a 

330-332. In a preferred embodiment of the present type of login process that may create a user account as 

invention, the authentication process 209 creates a local 25 needed on client 102A. At block 602, the dynamic login 

account using the values of the directory services user name process 510 begins. At block 604, workstation configuration 

345 and password 346, respectively. An administrator may, information contained in workstation object 305G is trans- 

however, provide an aUernate username 350 and password ferred to the client 102A at block 604 and stored in login 

351 to be used on the client. Importantly, the local credential settings 346 and, on a Windows NT client, in the Windows 

information 216 is maintained separately from the local 30 registry. If, at block 606, process 209 determines that server 

access database 203 and is modified as required by the credentials are enabled, that is, the server credentials flag 

authentication process 209 or time stamp mechanism 215. 318 is set, then the authentication process 209 performs a 

The local credentials 216 also includes login setting infor- process associated with server credentials at block 608. If 

mation 353 used to store workstation configuration infor- server credentials are not enabled, the authentication process 

mation such as volatile user flags, dynamic login flag, 35 209 performs a process associated with local credentials at 

among other information. Notably, the local credentials 216 block 610. At block 612, the dynamic login process 510 

may contain credential information sufiBcient to access client ends. 

102A, server 103 A, and server 103B. A process associated with server credentials is shown in 

A login process according to an embodiment of the FIG. 7. At block 702, the creation process 608 begins. At 

present invention is shown in FIG. 4. At block 402, the login 40 block 704, process 209 determines whether the user account 

process 400 begins. At block 404, the user enters credentials associated with the credential information provided by the 

within a login. The authentication process 209 stores the user exists in the local access database 203. If the account 

credential information provided by the user in the local exists, the local credentials 216 are simply transferred to the 

credentials 216. At block 406, the client 102 uses the security accessor 202. In a preferred embodiment, process 

credential information provided by the user to authenticate 45 209 synchronizes the password in the local access database 

the user with a directory services. As discussed, a user is 203 with the password from the directory services database 

authenticated to directory services by the directory services 223. That is, process 209 sets the value of the password in 

authenticator 221 which compares credential information the local access database 203 to the value of the password in 

provided by the user with credential records within the the directory services database having a usemame corre- 

directory services database 223. If authenticated, process 50 spending to the client user account. If the user account does 

400 then authenticates the user at the client workstation not exist, the authentication process 209, which executes as 

102A at block 410. At block 412 access to the client 102A an administrator user, creates a user account on the client 

is provided to the user by the security accessor 202, that is, 102A at block 708. As discussed above, the administrator 

the login process is complete and the client conducts normal account allows a user or process logged in as the adminis- 

operation. If server type 103B is provided in local creden- 55 trator to create, modify, or delete accounts in the local access 

tials 216, process 400 authenticates the cUent 102A with database 203. Process 209 may use the directory services 

server 103B. Normal operation is a period of operation user name as the user name for the client account. Sinailarly, 

wherein the client has authenticated the user to services process 209 may use the password associated with the 

associated with the credential information. The user wiU be directory services user name. When the account is created, 
authenticated to use the user account created by the authen- 60 the credentials for accessing the account are transferred to 

tication process 209, described in detail below. At block 414 the security accessor 202 at block 710. At block 712, the 

login process ends. server credentials process 608 ends. 

FIG. 5 shows, in more detail, a process for authenticating In FIG. 8, the process associated with local credentials is 

a user with directory services. At block 502 the authentica- shown. At block 802, the process for creating a user account 
tion process 406 begins. The credentials provided by the 65 on the chent 102A begins. If, at block 804, process 209 

user are transferred to 103A by the security accessor 202 determines that a user account corresponding to credential 

using networking protocol 201. Networking protocol 220 at information entered by the user at the client 102A exists, 
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then the local credential information 216 is transferred to the 
security accessor 202. If the user account does not exist, the 
authentication process 209 creates a user account in the local 
access database 203 according to configuration records 
contained in the workstation object 305G at block 808. At 5 
block 810, process 209 generates a random password asso- 
ciated with the user name 319 of the client workstation 
object 305G. The password in the local access database 203 
is set to the value of the generated random password at block 
812. At block 814, process 209 transfers credential infor- jg 
mation to the security accessor 202. At block 816, the local 
credentials process 610 ends. 

FIG. 9 shows a non -dynamic login process 512 according 
to an embodiment of the present invention. At block 902, the 
non-dynamic login process begins. If, at block 904, process 15 
209 attempts to login the user using the information defined 
by the user in local credentials 216, that is, using the 
directory services username 345 and password 346 or alter- 
nate usemame 350 and password 351, if provided. If the 
login attempt is successful, the non-dynamic login process 20 
ends at block 908. If the login attempt fails, a login error is 
displayed to the user and the login process ends at block 910. 
As an alternative, the user may be provided additional 
chances to enter a proper username and password, as 
needed. 25 

A user object inspection process 506 according to an 
embodiment of the present invention is shown in FIG. 10. At 
block 1002, the user object inspection process 605 begins. 
At block 104, the process 209 locates the client configura- 
tion by accessing objects in the directory services database 30 
223. Beginning with the user object 305D, process 209 
searches for an association to a client workstation object 
305G. As described above, such an association is repre- 
sented by the client workstation configuration pointer 312. If 
the value of pointer 312 is null, process 209 enumerates all 35 
of the groups to which the user object 305D belongs and 
checks the group objects for a client workstation configu- 
ration pointer 312 which points to a client workstation 
objection 305G. The first workstation object found by pro- 
cess 209 is tised for configuration of client 102A, If, at block 40 
1006, the user object 305D is associated with a client 
workstation objection 305G, the configuration information 
is read from the client workstation object 305G and trans- 
ferred to the client 102 A. If not, process 209 inspects the 
groups to which the user object 305D is a member at block 45 
1010. If, at block 1012, a group object is located that is 
associated with a workstation object 305G, the configuration 
of the client workstation object 305G is transferred to the 
client 102A and stored on the client 102A as described 
above. If not, process 209 will inspect the parent container 50 
object at block 1016. If, at block 1018, the parent container 
object is associated with a workstation objection, the con- 
figuration associated with the client workstation object 305G 
is transferred to the client 102A. If not, a default configu- 
ration is used to create the local user account at block 1022. 55 
At block 1024, the user object inspection process 506 ends. 

In FIG. 11, an exemplary logout process 1100 is shown. 
At block 1102, the logout process 1100 begins. At block 
1104, the authentication process 209 reads information in 
local credentials 216. Specifically, process 209 inspects the 60 
value of the dynamic login flag 317 as downloaded to login 
settings 346 during login. If, at block 1106, process 209 
determines that the user account currently being used was 
created as a volatile user account, then process 209 logs the 
user out of the desktop shell and deletes the local user profile 65 
from the registry and the user account firom the local access 
database 203. If process 209 determines that the user 



959 

18 

account was not volatile, process 209 logs the user out of the 
desktop shell at block 1112. At block 1112, process 1100 
ends. 

It should be understood, however, that embodiments of 
the invention may be directed to other types of clients, 
servers, and operating systems. Such embodiments may 
include a Windows NT client authenticating to a server 
executing the UNIX operating system, wherein the UNIX 
operating system maintains an authentication database such 
as the Network Information Service (NIS). Various embodi- 
ments of this type would be apparent to one skilled in the art 
of computer programming. 

Further, it should also be understood that the foregoing 
description has been directed to specific embodiments of this 
invention. It will be apparent, however, that other variations 
and modifications may be made to the described 
embodiments, to attain some or all of their advantages. 
Therefore, it is the object of the appended claims to cover all 
such variations and modifications to come within the true 
spirit and scope of the invention. 

What is claimed is: 

1. A method for managing user accounts in a communi- 
cations network having a client and server, the method 
comprising the steps of: 

a) logging in a user to the server having a database, the 
database having a first set of credential information 
wherein the database is a hierarchical directory services 
database having a user object that includes the first set 
of credential information; 

b) logging in the user to the client account using the first 
set of credential information; 

c) accessing a workstation object having associated con- 
figuration information; and 

d) based on the configuration information, generating an 
account on the client. 

2. The method according to claim 1, wherein step d) 
includes the steps of: 

1) starting a timer when the client account is generated; 
and 

2) deleting the client account when the timer exceeds a 
predetermined time. 

3. The method of claim 1, wherein step a) includes the 
steps of: 

1) transferring entered credentials to the server; 

2) inspecting a workstation object having login param- 
eters; 

3) logging in the user based upon the login parameters; 
and 

4) updating client credentials based upon the login param- 
eters. 

4. A system for providing a user authentication to a client 
workstation having a security accessor, the system compris- 
ing: 

a login process being operable to automatically create a 
user account on the client workstation; and 

a directory services authenticator providing credentials to 
the login process, wherein the login process authenti- 
cates a user to the security accessor using the creden- 
tials. 

5. A client-server system for managing user accounts in a 
distributed network, the system comprising: 

a directory services database having a plurality of network 
objects; and 

a client administrator associated with the directory ser- 
vices database, configured to create a plurality of client 
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objects in the directory services database, wherein each 
of said plurality of client objects represents a client 
system. 

6. The client-server system according to claim 5, further 
including means for associating one of the plurality of client 
objects to at least one of the plurality of network objects. 

7. The client-server system according to claim 6, wherein 
the at least one of the plurality of network objects is a user 
object representing a user. 

8. The client-server system according to claim 7, wherein 
at least one of said plurality of client objects includes login 
information associated with the user object. 

9. The client-server system according to claim 5, wherein 
each of said plurality of client objects includes login infor- 
mation. 

10. A method for managing user accounts in a commu- 
nications network having a client and a server, the method 
comprising the steps, of: 

a) logging in a user to a first server having a distributed 
database, the distributed database having a first set of 
credential information including a usemame and a 
password; 

b) locating a user account on the client, the user account 
having a same username as the first set of credential 
information; and 

c) synchronizing a password of the user account with the 
password of the first set of credential information. 

11. The method according to claim 10, wherein step a) 
includes the steps of: 



20 

1) transferring entered credentials to the server; 

2) inspecting a workstation object having login param- 
eters; 

5 3) logging in the user based upon the login parameters; 
and 

4) updating client credentials based upon the login param- 
eters. 

12. A method for managing user accounts in a commu- 
nications network having a client and a server, the method 
comprising steps of: 

a) logging in a user to a server having a directory services 
database; 

b) logging in the user at a client, wherein credentials for 
logging in the user to the server and client are synchro- 
nized. 

13. The method according to claim 12, further comprising 
20 automatically creating an account at the client if no previous 

account exists. 

14. The method according to claim 13, further comprising 
automatically deleting the account after a predetermined 
amount of time. 

25 

15. The method according to claim 14, wherein the 
predetermined amount of time is measured from an end of 
a last login period of the tiser. 

* « * « * 
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